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Introduction 


The IETF TRILL (Transparent Interconnection of Lots of Links) 
protocol [RFC6325] [RFC7780] provides optimal pair-wise data frame 
forwarding without configuration, safe forwarding even during periods 
of temporary loops, and support for multipathing of both unicast and 
multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] 
[RFC7176] link state routing and encapsulating traffic using a header 
that includes a hop count. Devices that implement TRILL are called 
"RBridges" (Routing Bridges) or "TRILL Switches". 


An RBridge that attaches to endnodes is called an "edge RBridge" or 
"edge TRILL Switch", whereas one that exclusively forwards 
encapsulated frames is known as a "transit RBridge" or "transit TRILL 
Switch". An edge RBridge traditionally is the one that encapsulates 
a native Ethernet frame with a TRILL header or that receives a TRILL- 
encapsulated packet and decapsulates the TRILL header. To 
encapsulate efficiently, the edge RBridge must keep an "endnode 
table" consisting of (Media Access Control (MAC), Data Label, TRILL 
egress switch nickname) sets, for those remote MAC addresses in Data 
Labels currently communicating with endnodes to which the edge 
RBridge is attached. 


These table entries might be configured, received from End Station 
Address Distribution Information (ESADI) [RFC7357], looked up ina 
directory [RFC7067], or learned from decapsulating received traffic. 
If the edge RBridge has attached endnodes communicating with many 
remote endnodes, this table could become very large. Also, if a MAC 
address / Data Label pair in the table have moved to a different 
remote TRILL switch, it might be difficult for the edge RBridge to 
notice this quickly; and because the edge RBridge is encapsulating to 
the incorrect egress RBridge, the traffic will get lost. 


Conventions Used in This Document 
1. Terminology 


BUM: Broadcast, Unknown unicast, and Multicast. 


Edge RBridge: An RBridge providing endnode service on at least one of 
its ports. It is also called an edge TRILL Switch. 


Data Label: VLAN or FGL. 
DRB: Designated RBridge [RFC6325]. 


ESADI: End Station Address Distribution Information [RFC7357]. 
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FGL: Fine-Grained Label [RFC7172]. 

IS-IS: Intermediate System to Intermediate System [IS-IS]. 

LSP: Link State PDU. 

PDU: Protocol Data Unit. 

RBridge: Routing Bridge, an alternative name for a TRILL switch. 
Smart Endnode: An endnode that has the capability specified in this 
document including learning and maintaining (MAC, Data Label, 


nickname) entries and encapsulating/decapsulating TRILL frame. 


Transit RBridge: An RBridge that exclusively forwards encapsulated 
frames. It is also called a transit TRILL Switch. 


TRILL: Transparent Interconnection of Lots of Links 
[RFC6325] [RFC7780]. 


TRILL ES-IS: TRILL End System to Intermediate System, is a variation 
of TRILL IS-IS designed to operate on a TRILL link among and between 
one or more TRILL switches and end stations on that link [RFC8171]. 


TRILL Switch: a device that implements the TRILL protocol; an 
alternative term for an RBridge. 


Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Solution Overview 


The Smart Endnode solution defined in this document addresses the 
problem of the size and freshness of the endnode learning table in 
edge RBridges. An endnode E, attached to an edge RBridge R, tells R 
that E would like to be a "Smart Endnode", which means that E will 
encapsulate and decapsulate the TRILL frame, using R’s nickname. 
Because E uses R’s nickname, this solution does not consume extra 
nicknames. 
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Take Figure 1 as the example Smart Endnode scenario: RB1, RB2, and 
RB3 are the RBridges in the TRILL domain and SE1 and SE2 are the 
Smart Endnodes that can encapsulate and decapsulate the TRILL 
packets. RB1 is the edge RB to which SE1 and SE2 have attached. RB1 
assigns one of its nicknames to be used by SE1 and SE2. 


Each Smart Endnode, SE1 and SE2, uses RB1’s nickname when 
encapsulating and maintains an endnode table of (MAC, Data Label, 
TRILL egress switch nickname) for remote endnodes that it (SE1 or 
SE2) is corresponding with. RB1l does not decapsulate packets 
destined for SE1 or SE2 and does not learn (MAC, Data Label, TRILL 
egress switch nickname) for endnodes corresponding with SE1 or SE2, 
but RB1 does decapsulate and does learn (MAC, Data Label, TRILL 
egress switch nickname) for any endnodes attached to RB1 that have 
not declared themselves to be Smart Endnodes. 


Just as an RBridge learns and times out (MAC, Data Label, TRILL 
egress switch nickname), Smart Endnodes SE1 and SE2 also learn and 
time out endnode entries. However, SE1 and SE2 might also determine, 
through ICMP messages or other techniques that an endnode entry is 
not successfully reaching the destination endnode, and it can be 
deleted, even if the entry has not timed out. 


If SE1 wishes to correspond with destination MAC D, and no endnode 
entry exists, SE1 will encapsulate the packet as an unknown 
destination, or consult a directory [RFC7067] (just as an RBridge 
would do if there was no endnode entry). 


4+---------- + 
|SE1(Smart | 
|Endnodel) | \ Sa a AE EE + 
fo aes ee +  \ / \ 

\ /+------ + +----- + psss + \ to- saa + 

/-+-| RB 1 |---| RB2 |----| RB3 |----- +-- | Endnode3 

/ | +------ +  +------ + +----- + |  [MAC=D 

Sa + / \ / to-- 77-7 + 
|SE2(Smart | \ / 
| Endnode2) | TESS SRR SSS SS eno SSS SaaS SSSane a 
4+---------- + 


Figure 1: Smart Endnode Scenario 
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The mechanism in this document is that the Smart Endnode SE1 issues a 
Smart-Hello, indicating SE1’s desire to act as a Smart Endnode, 

together with the set of MAC addresses and Data Labels that SE1 owns. 
The Smart-Hello is used to announce the Smart Endnode capability and 


parameters (such as MAC address, Data Label, etc.). The Smart-—Hello 
is a type of TRILL ES-IS PDU, which is specified in Section 5 of 
[RFC8171]. The detailed content for a Smart Endnode’s Smart-—Hello is 


defined in Section 4. 


If RB1 supports having a Smart Endnode neighbor, it also sends Smart- 
Hellos. The Smart Endnode learns from RB1’s Smart-Hellos what RB1’s 
nickname is and which trees RB1 can use when RB1 ingresses multi- 
destination frames. Although Smart Endnode SH1 transmits Smart- 
Hellos, it does not transmit or receive Link State PDUs (LSPs) or 
Extended Level 1 Flooding Scope (E-L1FS) FS LSPs [RFC7780]. 


Since a Smart Endnode can encapsulate TRILL Data packets, it can 
cause the Inner.Label to be a Fine-Grained Label [RFC7172]; thus, 
this method supports FGL-aware endnodes. When and how a Smart 
Endnode decides to use the FGL instead of VLANs to encapsulate the 
TRILL Data packet is out of scope in this document. 


4. Smart—-Hello Mechanism between Smart Endnode and RBridge 


The subsections below describe Smart-—Hello messages. 


4.1. Smart-Hello Encapsulation 


Although a Smart Endnode is not an RBridge, does not send LSPs or 
maintain a copy of the link state database, and does not perform 
routing calculations, it is required to have a "Hello" mechanism (1) 
to announce to edge RBridges that it is a Smart Endnode and (2) to 
tell them what MAC addresses it is handling in what Data Labels. 
Similarly, an edge RBridge that supports Smart Endnodes needs a 
message (1) to announce that support, (2) to inform Smart Endnodes 
what nickname to use for ingress and what nickname(s) can be used as 
egress nickname in a multi-destination TRILL Data packet, and (3) the 
list of Smart Endnodes it knows about on that link. 


The messages sent by Smart Endnodes and by edge RBridges that support 
Smart Endnodes are called "Smart-Hellos". The Smart-Hello is a type 
of TRILL ES-IS PDU, which is specified in [RFC8171]. 
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The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes 
and for Smart-—Hellos sent by edge RBridges, consists of TRILL IS-IS 
TLVs as described in the following two subsections. The non-extended 
format is used so TLVs, sub-TLVs, and APPsub-TLVs have an 8-bit size 
and type field. Both types of Smart-Hellos MUST include a Smart- 
Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV: 


+-+-+-+-+-+-+-+-+- 


| Smart-Parameters | (1 byte) 
+-+-+-+-+-+-+-+-+- 

| Length | (1 byte) 
+=-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Holding Time | (2 bytes) 
+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Flags | (2 bytes) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 2: Smart-Parameters APPsub-TLV 
o Type: APPsub-TLV type Smart-Parameters, value is 22. 
o Length: 4. 


o Holding Time: A time in seconds as an unsigned integer. It has 
the same meaning as the Holding Time field in IS-IS Hellos 
[IS-IS]. A Smart Endnode and an edge RBridge supporting Smart 
Endnodes MUST send a Smart-Hello at least three times during their 
Holding Time. If no Smart-Hellos are received from a Smart 
Endnode or edge RBridge within the most recent Holding Time it 
sent, it is assumed that it is no longer available. 


o Flags: At this time, all of the Flags are reserved and MUST be 
sent as zero and ignored on receipt. 


o If more than one Smart-Parameters APPsub-TLV appears in a Smart- 
Hello, the first one is used and any following ones are ignored. 
If no Smart-Parameters APPsub-TLVs appear in a Smart-Hello, that 
Smart-Hello is ignored. 
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4.2. Edge RBridge’s Smart-—Hello 


The edge RBridge’s Smart-Hello contains the following information in 
addition to the Smart—Parameters APPsub-TLV: 


o RBridge’s nickname. The nickname sub-TLV, specified in 
Section 2.3.2 in [RFC7176], is reused here carried inside a TLV 
242 (IS-IS router capability) in a Smart-Hello frame. If more 
than one nickname appears in the Smart-Hello, the first one is 
used and the following ones are ignored. 


o Trees that RB1 can use when ingressing multi-destination frames. 
The Tree Identifiers sub-TLV, specified in Section 2.3.4 in 
[RFC7176], is reused here. 


o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in 
section 2.5 in [RFC7176], is reused for this purpose. 


o An Authentication TLV MAY also be included. 
4.3. Smart Endnode’s Smart—Hello 


A new APPsub-TLV (Smart-MAC TLV) for use by Smart Endnodes is as 


defined below. In addition, there will be a Smart-Parameters APPsub- 
TLV and there MAY be an Authentication TLV in a Smart Endnode Smart- 
Hello. 


If there are several VLANs/FGL Data Labels for that Smart Endnode, 
the Smart-MAC APPsub-TLV is included several times in the Smart 
Endnode’s Smart-Hello. This APPsub-TLV appears inside a TRILL 
GENINFO TLV. 
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| Type=Smart-MAC 
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| Length 


-+ 
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+-4+-4-4-4-4-4-4-4+-4+-4+-4+-4+-4+-4+-4+-4-4-4-4-4 


|F|M| RSV 
+-+-+-+-+-+-+-+ 
| 
+-+-+-+-+-+-+-+ 
| 
+—-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+ 


=+- 


=+- 


—-+—-— 


+- 


VLAN/FGL Data Label | (4 bytes) 
+-+-+-+-+-+-+-+-+-. . .+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
MAC (1) (6 bytes) | 
+-+-+-+-+-+-+-+-+-. . .+-+-+-+-+-+-+-+-+-+-+-+-+-+- + 
E a re ee EEE. 
MAC (N) (6 bytes) | 
+-+-+-+-+-+-+-+-+-. . .+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: Smart-MAC APPsub-TLV 


o Type: TRILL APPsub-TLV Type Smart-MAC, value is 23. 


o Length: Total number of bytes contained in the value field of the 
the sum of the length of the F/M/RSV/FGL Data Label 
fields and six times the number of MAC addresses present. So, if 
there are n MAC addresses, this is 4+6*n. 


TLV, that is, 


o F: 1 bit. If it is set to 1, it indicates that the endnode 
supports FGL Data Labels [RFC7172], and that this Smart—MAC 
APPsub-TLV has an FGL in the following VLAN/FGL field. Otherwise, 
the VLAN/FGL Data Label field is a VLAN ID. (See below for the 
format of the VLAN/FGL Data Label field). 


o M: 1 bit. If it is set to 1, it indicates multihoming (see 


Section 6). 


If 


it is set to 0, it indicates that the Smart 


Endnodes are not using multihoming. 


o RSV: 6 bits; 


reserved for the future use. 


o VLAN/FGL Data Label: 24 bits. If F is 1, this field is a 24-bit 
FGL Data Label for all subsequent MAC addresses in this APPsub- 


TLV. Otherwise, 


if F is 0, the lower 12 bits are the VLAN of all 


subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits 
(sent as zero and ignored on receipt). If there is 
no VLAN/FGL Data Label specified, the VLAN/FGL Data Label is zero. 


are not used 


o MAC(i): This is a 48-bit MAC address reachable in the Data Label 
sent by the Smart Endnode that is announcing this APPsub-TLV. 
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5. 


Processing Data Packets 


The subsections below specify the processing of Smart Endnode data 

packets. All TRILL Data packets sent to or from Smart Endnodes are 
sent in the Designated VLAN [RFC6325] of the local link but do not 

necessarily have to be VLAN tagged. 


1. Data-Packet Processing for Smart Endnodes 


A Smart Endnode does not issue or receive LSPs or E-L1FS FS LSPs or 
calculate topology. It does the following: 


o A Smart Endnode maintains an endnode table of (the MAC address of 
remote endnode, Data Label, the nickname of the edge RBridge’s 
attached) entries of end nodes with which the Smart Endnode is 
communicating. Entries in this table are populated the same way 
that an edge RBridge populates the entries in its table: 


* learning from (source MAC address ingress nickname) on packets 
it decapsulates. 


* by querying a directory [RFC7067]. 
* by having some entries configured. 


o When Smart Endnode SE1 wishes to send unicast frame to remote node 
D, if the (MAC address of remote endnode D, Data Label, nickname) 
entry is in SE1’s endnode table, SE1 encapsulates the ingress 
nickname as the nickname of the RBridge (RB1), egress nickname as 
indicated in D’s table entry. If D is unknown, SE1l either queries 
a directory or encapsulates the packet as a multi-destination 
frame, using one of the trees that RB1 has specified in RB1’s 
Smart-Hello. The mechanism for querying a directory is given in 
[RFC8171]. 


o When SE1 wishes to send a Broadcast, Unknown Unicast, and 
Multicast (BUM) packet to the TRILL campus, SE1l encapsulates the 
packet using one of the trees that RB1 has specified. 


If the Smart Endnode SE1 sends a multi-destination TRILL Data packet, 
the destination MAC of the outer Ethernet is the All-RBridges 
multicast address. 


The Smart Endnode SE1 need not send Smart-Hellos as frequently as 
normal RBridges. These Smart-Hellos could be periodically unicast to 
the Appointed Forwarder RB1. In case RB1 crashes and restarts, or 
the DRB changes and SE1 receives the Smart-Hello without mentioning 
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SE1, SE1 SHOULD send a Smart-Hello immediately. If RB1 is Appointed 
Forwarder for any of the VLANs that SE1 claims, RB1 MUST list SE1 in 
its Smart-Hellos as a Smart Endnode neighbor. 


5.2. Data-Packet Processing for Edge RBridge 


The attached edge RBridge processes and forwards TRILL Data packets 
based on the endnode property rather than for encapsulation and 
forwarding the native frames the same way as the traditional 
RBridges. There are several situations for the edge RBridges as 
follows: 


o If receiving an encapsulated unicast TRILL Data packet from a port 
with a Smart Endnode, with RB1’s nickname as ingress, the edge 
RBridge RB1 forwards the frame to the specified egress nickname, 
as with any encapsulated frame. However, RB1 SHOULD filter the 
encapsulation frame based on the inner source MAC and Data Label 
as specified for the Smart Endnode. If the MAC (or Data Label) is 
not among the expected entries of the Smart Endnode, the frame 
would be dropped by the edge RBridge. If the edge RBridge does 
not perform this check, it makes it easier for a rogue end station 
to inject bogus TRILL Data packets into the TRILL campus. 


o If receiving a unicast TRILL Data packet with RB1’s nickname as 
egress from the TRILL campus, and the destination MAC address in 
the enclosed packet is a MAC address that has been listed by a 
Smart Endnode, RB1 leaves the packet encapsulated to that Smart 
Endnode. The outer Ethernet destination MAC is the destination 
Smart Endnode’s MAC address, the inner destination MAC address is 
either the Smart Endnode’s MAC address or some other MAC address 
that the Smart Endnode advertised in its Smart Hello, and the 
outer Ethernet source MAC address is the RB1’s port MAC address. 
The edge RBridge still decreases the Hop count value by 1, for 
there is one hop between the RB1 and Smart Endnode. 


o If receiving a multi-destination TRILL Data packet from a port 
with a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation 
to the TRILL campus based on the distribution tree indicated by 
the egress nickname. If the egress nickname does not correspond 
to a distribution tree, the packet is discarded. If there are any 
normal endnodes (i.e., endnodes that are not Smart Endnodes) 
attached to the edge RBridge RB1, RB1 decapsulates the frame and 
sends the native frame to these ports possibly pruned based on 
multicast listeners, in addition to forwarding the multi- 
destination TRILL frame to the rest of the campus. 
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6. 


If RB1 receives a native multi-destination data frame, which is 
sent by an endnode that is not a Smart Endnode, from a port, 
including hybrid endnodes (Smart Endnodes and endnodes that are 
not Smart Endnodes), RB1 will encapsulate it as multi-destination 
TRILL Data packet, and send the encapsulated multi-destination 
TRILL Data packet out that same port to the Smart Endnodes 
attached to the port, and also send the encapsulated multi- 
destination TRILL Data packet to the TRILL campus through other 
ports. 


If RB1 receives a multi-destination TRILL Data packet froma 
remote RBridge, and the exit port includes hybrid endnodes (Smart 
Endnodes and endnodes that are not Smart Endnodes), it sends two 
copies of multicast frames out the port, one as native and the 
other as a TRILL-encapsulated frame. When a Smart Endnode 
receives a multi-destination TRILL Data packet, it learns the 
remote (MAC address, Data Label, nickname) entry. A Smart Endnode 
ignores native data frames. A normal (non-Smart) endnode receives 
the native frame and learns the remote MAC address and ignores the 
TRILL Data packet. This transit solution may bring some 
complexity for the edge RBridge and waste network bandwidth 
resource, so avoiding the hybrid endnodes scenario by attaching 
the endnodes that are Smart and non-Smart to different ports is 
RECOMMENDED. 


Multihoming Scenario 


Multihoming is a common scenario for the Smart Endnode. The Smart 
Endnode is on a link attached to the TRILL domain in two places: edge 
RBridges RB1 and RB2. Take Figure 4 as an example. The Smart 
Endnode SE1 is attached to the TRILL domain by RB1 and RB2 
separately. Both RB1 and RB2 could announce their nicknames to SE1. 


+------ + 

| RB1 | 

/+------ + 
4+---------- ares +----- Fes +---------- + 
|SE1(Smart |/. | RBS [iaa | Smart | 
| Endnode1)| .\ +----- +. | Endnode2 | 
+---------- +. N +---------- + 

+----- + 

| RB2 | TRILL 

Fossas + Domain 


Figure 4: Multihoming Scenario 
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Smart Endnode SE1 can choose either the nickname of RB1 or RB2 when 
encapsulating and forwarding a TRILL Data packet. If the active- 
active load balance is considered for the multihoming scenario, the 


Smart Endnode SE1 could use both the nickname of RB1 and RB2 to 
encapsulate and forward TRILL Data packet. SE1 uses RB1’s nickname 
when forwarding through RB1 and RB2’s nickname when forwarding 
through RB2. This will cause MAC flip-flopping (see [RFC7379]) of 
the endnode table entry in the remote RBridges (or Smart Endnodes). 
The solution for the MAC flip-flopping issue is to set a multihoming 
bit in the RSV field of the TRILL Data packet. When remote RBridge 
RB3 or Smart Endnodes receive a data packet with the multihomed bit 
set, the endnode entries (SE1’s MAC address, label, RB1’s nickname) 
and (SE1’s MAC address, label, RB2’s nickname) will coexist as 
endnode entries in the remote RBridge. (An alternative solution 
would be to use the ESADI protocol to distribute multiple attachments 
of a MAC address of a multihoming group. The ESADI is deployed among 
the edge RBridges (see Section 5.3 of [RFC7357]). 


7. Security Considerations 


Smart-Hellos can be secured by using Authentication TLVs based on 
[RFC5310]. If they are not secured, then it is easier for a rogue 
end station that does not posses the required keying material to be 
falsely recognized as a valid Smart Endnode. 


For general TRILL Security Considerations, see [RFC6325]. As stated 
there, since end stations are connected to edge RBridge ports by 
Ethernet, those ports MAY require end stations to authenticate 
themselves using [IEEE802.1X] and authenticate and encrypt traffic 
to/from the RBridge port with [IEEE802.1AE]. 


If they misbehave, Smart Endnodes can forge arbitrary ingress and 
egress nicknames in the TRILL headers of the TRILL Data packets they 
construct. Decapsulating at egress RBridges or remote Smart Endnodes 
that believe such a forged ingress nickname would send future traffic 
destined for the inner-source MAC address of the TRILL data frame to 
the wrong edge RBridge if data-plane learning is in use. Because of 
this, an RBridge port should not be configured to support Smart 
Endnodes unless the end stations on that link are trusted or can be 
adequately authenticated. 


As with any end station, Smart Endnodes can forge the outer MAC 
addresses of packets they send (see Section 6 of [RFC6325].) Because 
they encapsulate TRILL Data packets, they can also forge inner MAC 
addresses. The encapsulation performed by Smart Endnodes also means 
they can send data in any Data Label, which means they must be 
trusted in order to enforce a security policy based on Data Labels. 
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The TRILL-Hello is a type of TRILL ES-IS and is defined in [RFC8171]. 
Receiving and processing TRILL-Hello for RBridges and Smart Endnodes 

would not bring more security and vulnerability issues than the TRILL 
ES-IS security defined in [RFC8171]. 


For added security against the compromise of data due to its 
misdelivery for any reason, including the above, end-to-end 
encryption and authentication should be considered; that is, 
encryption and authentication from source end station to destination 
end station. 


The mechanism described in this document requires Smart Endnodes to 
be aware of the MAC address(es) of the TRILL edge RBridge(s) to which 
they are attached and the egress RBridge nickname from which the 
destination of the packets is reachable. With that information, 
Smart Endnodes can learn a substantial amount about the topology of 
the TRILL domain. Therefore, there could be a potential security 
risk when the Smart Endnodes are not trusted or are compromised. 


8. IANA Considerations 
IANA has allocated APPsub-TLV type numbers for the Smart-MAC and 


Smart-Parameters APPsub-TLVs. The "TRILL APPsub-TLV Types under 
IS-IS TLV 251 Application Identifier 1" registry has been updated as 


follows. 
t----------- to-- 55-555 ta SaaasSeas + 
| Protocol | Description | Reference | 
4+----------- 4-55-55 4------------ + 
| 22 | Smart-Parameters | RFC 8384 | 
| 23 | Smart-MAC | RFC 8384 | 
A A NTE E a E E EA EE t------------ + 
Table 1 
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